Software applications are often updated through installation of a software update, also known as a “patch”. For many applications, the installation of a patch takes only a few minutes. Therefore, one common way to update an application is to shut down the application to make it inaccessible to a user or users, install the patch, and then restart the updated, or patched, application to make it accessible to users again.
However, for some large and complex applications, the installation of a patch is a long and drawn-out process that may take many hours or even many days. For this type of application, shutting down the application in order to install a patch may result in the application being inaccessible to users for an unacceptably long period of time. Therefore, one solution is to make a copy of the application, install the patch to the copy of the application while the original application continues to service users, and then upon the completion of the patch installation to the copy of the application, commence the servicing of users by the patched copy of the application before shutting down the original application. This solution allows a patch to be installed without disrupting the accessibility of users to the application.
This solution, however, is inadequate for applications that contain metadata. Metadata is not part of the application code itself, nor is it part of the data that the application processes in its normal operation. Rather, metadata is data that controls and alters the behavior of the code in an application. Metadata can be included as part of an application, and is typically stored in a repository (either a database or file system) that is shared by all modules of the application. Because the application depends on metadata for correct operation, a patch to the application may contain metadata. Finally, users utilizing an application may also be modifying the metadata contained in the application as user customizations. Examples of user-customizations that modify the metadata of an application include: user interface elements, custom rule definitions, and definitions of reports to run. Because users may continue to make customizations as part of their utilization of the application, a simple solution involving only the patching of a copy of the application, such as the one just described, does not successfully carry over user customizations to the patched application.
The existence of metadata increases the difficulty of patching an application without downtime because each version of the application is typically built with its own version of metadata. Thus, installation of new metadata usually causes an older version of the application to fail or work incorrectly. Application developers can work around this problem by modifying the new metadata to be compatible with the old version of the application. However, this incurs significant cost in human time and effort, and may not be feasible in all cases.
Therefore, it is desirable to develop techniques for patching applications that contain user-modifiable metadata in an efficient manner and with minimal reduced utility for the user.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.